Date: Thu,  9 Dec 93 04:30:31 PST
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #141
To: Ham-Digital


Ham-Digital Digest          Thu,  9 Dec 93       Volume 93 : Issue  141

Today's Topics:
                        ATM on Amateur Radio?
                    Digital with Sound Blaster???
                        F6FBB release 5.15b ?
       How much time does a G3RUH modem take to acquire signal?
                 Looking for NOS Executable with NNTP
          Need advice on using tube-final rigs for RTTY/AFSK
                             TEKK Radios
             Understanding AX.25 Packet monitored frames
                  W9GR DSP article of Sept 1992 QST

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 6 Dec 1993 20:35:10 GMT
From: nntp.ucsb.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!metropolis.gis.iastate.edu!willmore@network.ucsd.edu
Subject: ATM on Amateur Radio?
To: ham-digital@ucsd.edu

karn@unix.ka9q.ampr.org (Phil Karn) writes:
>OSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein) writes:
>|> ATM breaks packets up into cells, the idea being that an time
>|> critical (voice or video) packet can't affort to be held back
>|> because a long (4k bytes?)  packet is being sent.  So all packets
>|> are broken into cells, which can then be sent as needed (critical
>|> ones first).
>|> 
>|> Well, it appears that this solves the problem.  Only on a 1Gbit
>|> link a 4K byte packets is only 32 microseconds long so the
>|> problem doesn't really exist for this speed link!

>Absolutely! But you must understand the real driving factor behind the
>design of ATM: voice. For all their lip service of "integrated"
>voice/data/video services and supporting the Information Age, voice is
>still the telcos' bread and butter, and it's the only thing they
>consider important.  For example, the specific frame size chosen for
>ATM (48 bytes of data + 5 bytes of header) was picked to minimize the
>packetizing delay for conventional 64kb/s digital voice, so as to
>avoid having to use echo cancellers to take care of reflections off of
>the hybrids in the analog local loops at the ends of a voice
>call. (The degree to which people object to an echo of a given
>amplitude is a strong function of its delay -- the longer the delay,
>the more annoying it is).  To be sure, this choice was more the fault
>of the Europeans than the Americans, who wanted a somewhat larger cell
>size.

------------------------------

Date: Tue, 7 Dec 1993 15:41:48 GMT
From: usc!howland.reston.ans.net!pipex!bnr.co.uk!corpgate!nrtpa038!b4pph13e!cnc23a@network.ucsd.edu
Subject: Digital with Sound Blaster???
To: ham-digital@ucsd.edu

In your previous article, you wrote:

> Can someone please tell me if there is any software that uses a Sound
> Blaster to receive CW,RTTY,SSTV,PACKET,etc,etc. 
> 
> Thanks, 73,
> -- 
> Scott R. Weis KB2EAR
> Internet: kb2ear@kb2ear.ampr.org
> Snail Mail: 10 Palmer Rd., Kendall Park, NJ, 08824-1228
> Phone:  +1 908 297 0469


I'm sorry for not e-mailing, but my mail sys is funny.  

For CW : FFTMORSE by Francois Jalbert (jalbert@IRO.UMontreal.CA)

For SSTV: SLOWSC by Gene Harlan WB9MMM

For DTMF: _DMTF by Peter Jennings VE3SUN

I found these on my SIMTEL CD, 

a local ham has developed a RTTY program, but has not generally released it.

PACKET ????



Hope this is of some help.    

   73s es CUL    N4ZBB



-- 
======================================================================

Ken M. Edwards, PE  Bell Northern Research, Research Triangle Park, NC
(919) 481-8476 email: cnc23a@bnr.ca    Ham: N4ZBB

All opinions are my own and do not necessarily reflect the views of
my employer or co-workers, family, friends, congress, or president.

(To the e-mail'r out there -> This is a short as it will gets)

------------------------------

Date: 9 Dec 93 11:03:29 GMT
From: news-mail-gateway@ucsd.edu
Subject: F6FBB release 5.15b ?
To: ham-digital@ucsd.edu

Can someone please tell me if is available the new release 5.15b of the
F6FBB bbs software ? If so, where can be ftp'ed ?
Tks, 73,

Luiz Catalan
internet: catalan@vortex.ufrgs.br
packet: pp5aq@pp5aq.bra.sa

------------------------------

Date: 9 Dec 93 06:41:00 GMT
From: news-mail-gateway@ucsd.edu
Subject: How much time does a G3RUH modem take to acquire signal?
To: ham-digital@ucsd.edu

When a 9600 baud modem of the G3RUH/K9NG-type hears a signal, how long
does it take (or more accurately, how many bit periods) does it take to
begin to properly decode data?

If it is just a matter of getting a few bit periods to sync the state machine,
and then, say, 17 more to get the descrambler working, then 20 milliseconds
should be more than enough time to get things working.

In practical experience, how long *does* it take for the modem to start
decoding data properly (at 9600 baud?)

Thanks,

<Clint>

------------------------------

Date: Fri, 3 Dec 1993 15:10:22 GMT
From: agate!howland.reston.ans.net!EU.net!sun4nl!hacktic!utopia.hacktic.nl!globv1.hacktic.nl!peter@ames.arpa
Subject: Looking for NOS Executable with NNTP
To: ham-digital@ucsd.edu

ron@alpha.nsula.edu (Ron Wright) writes:

>I am looking for a compiled version of NOS that has the NNTP server compiled 
>in.  I do not currently have a compiler so I can't put together my own.  Along 
>these lines...

WNOS has nntp support built in. It's on ucsd.edu:/hamradio/packet/tcpip/wnos.

>Does anyone know of the GNU c++ compiler will successfuly 
>compile NOS.

You mean DJGPP, the GCC compiler for MS-DOS? If so, then the answer is no.

Groetjes,
Peter Busser
-- 
Linux, the choice of a GNU generation.

------------------------------

Date: 7 Dec 1993 13:07:29 +0200
From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!EU.net!news.funet.fi!klaava!klaava!not-for-mail@network.ucsd.edu
Subject: Need advice on using tube-final rigs for RTTY/AFSK
To: ham-digital@ucsd.edu

I'll be shopping for a used rig soon and will be on a very tight
budget, so I'm trying to get a picture of what the minimal rig would be
that will do what I want. Other than SSB/CW, I've been itching to get
into RTTY, but have heard that many older rigs have problems both from
the 100% duty cycle and sluggish operation.

I'm intrested in hearing people's experiences working the various
digital modes on HF using older tube rigs, or rigs with tube finals.
More than likely, I'll be using a late-model multimode TNC and AFSK for
HF RTTY/Baudot/AMTOR. What sort of things should I look for in a
suitable rig. Obviously, the quality of the SSB signal is more
important when using AFSK rather than FSK (right?). How can one
estimate the max. drive the finals can take at 100% duty cycle? How
can one determine if the tx is "fast" enough (or is sluggishness
only a problem with FSK and not AFSK?).

Of course, I'd particularly appreciate any recommendations for (or
against) particular rigs, which would help me in my shopping.

Thanks,


/////////////////////////////////////////////////////////////////////////
  Patrick M. Stickler  OH2LUV, KC4YYY    The comments contained herein
  WSOY - Information Systems Division    do not necessarily reflect the
  Helsinki, FINLAND    (psti@wsoy.fi)    official views of my employer.
/////////////////////////////////////////////////////////////////////////

------------------------------

Date: Tue, 7 Dec 1993 02:45:12 GMT
From: netcomsv!netcom.com!fmitch@decwrl.dec.com
Subject: TEKK Radios
To: ham-digital@ucsd.edu

tekk has a special on the little data radios until the end of the
year... call them for details... 800-521-8355...

mitch, wa4osr

-- 
-------------------------------------------------------------------------------
fmitch@netcom.com
Felton "Mitch" Mitchell, WA4OSR in Mobile, Alabama USA
205-342-7259 home, 205-476-4100 work, 205-476-0465 FAX
co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DXCluster in Mobile..
------------------------------------------------------------------------------

------------------------------

Date: 8 Dec 93 16:25:28 GMT
From: news-mail-gateway@ucsd.edu
Subject: Understanding AX.25 Packet monitored frames
To: ham-digital@ucsd.edu

                     UNDERSTANDING MONITORED PACKET FRAMES

                               Don Rotolo N2IRZ

Have you ever monitored the packet channel and wondered just what all those
letters and numbers at the beginning of each packet "frame" mean ?  Well,
wonder no more !  This article will explain the basics of packet control.

All packet HDLC (High-level Data Link Control) frames are similar, consisting
of 6 unique "fields":

    | Flag | Address | Control | PID & Data | FCS | Flag |

FLAG : The Flag fields are put at the beginning and end of each frame to
        indicate the boundaries of the frame. A unique bit sequence is used
        (01111110) so other parts of the frame won't be mistaken for a Flag.

ADDRESS: This field normally specifies the destination of the frame. This is
        the actual call signs of the source, destination, and any digipeaters.

CONTROL: This field identifies the frame type. See FRAME TYPES below.

PID: The first byte of the Data field is the Protocol ID, specifying the
        type of protocol in use.

DATA: This is the actual data to be transferred.  Many frames do not have a
        data field.

FCS: Frame Check Sequence, this is how errors are detected in a frame. Your
        TNC creates a number based on the rest of the fields, using a special
        mathematical formula.  The other TNC does the same, and if the numbers
        match, the frame has no errors and is accepted.

We will examine a typical frame:

KD6TH-4>N2DSY-2*>N2IRZ [I;3,1]:0042z, 838 msgs, #40407 last @KD6TH-4 Mailbox>
<----Address---------> <-----> <----------Data------------------------------>
                       Control

Note that you do not see the Flag, PID and FCS fields.

FRAME TYPES:

  C     Connect frame. Also known as a 'SABM' frame (Set Asynchronous Balanced
         Mode).
  D     Disconnect frame.
  DM    Disconnect Mode frame.
  I     Information frame.
  UA    Unnumbered Acknowledgement frame.
  UI    Unnumbered Information frame.
  RR    Receive Ready command and response.
  RJ    ReJect frame.
  RNR   Receive Not Ready command and response.
  FRMR  FRaMe Reject response.
  DM    Disconnected Mode response.

When you type into your TNC a connect command, the TNC generates a frame like:

N2IRZ*>KD6TH-4 [C,P]

This means that N2IRZ is trying to connect to KD6TH-4.  The * shows who is
transmitting.  The > shows the direction the frame is going (to KD6TH-4). The
"C" indicates that it is a Connect frame, and the "P" means that the "Poll"
bit is set.  When the Poll bit is set, it means the originating station is
Polling (or "searching") for the destination station (sort of asking "are you
there ??").  If the destination station was to respond, it would send an "F",
or Final, bit in response ("yep, I'm here"). If the radio path is "perfect",
the Poll/Final bits will rarely be used again.

KD6TH-4 is able to establish a connection to N2IRZ, so it sends:

KD6TH-4*>N2IRZ [UA,F]

This means that KD6TH-4 has acknowledged receiving N2IRZ's Connect request,
and confirms the connection. Your TNC generates the familiar "*** Connected to
..." message for you. KD6TH-4 now sends a greeting (his "Connect Text"):

KD6TH-4*>N2IRZ [I,P;0,0]:Hi Don, Welcome to KD6TH-4 BBS !

The "I" tells us that this is an information frame.  The information (Hi
Don...) can be any text. P is for Polling - KD6TH-4 is just making sure N2IRZ
is still there.  What is interesting here are the numbers in the "[I,P;0,0]:"
part: The first number is the next frame number that KD6TH-4 expects from
N2IRZ, and the second number is the number of the frame that is being sent.
The order of the numbers switches when N2IRZ is sending. Upon receiving this
frame without errors, N2IRZ sends:

N2IRZ*>KD6TH-4 [RR,F;1]

Telling KD6TH-4 that N2IRZ got frame 0 OK and is ready to receive frame 1.
KD6TH-4 sends 2 more info frames to N2IRZ:

KD6TH-4*>N2IRZ [I;0,1]:*** You have Unread Mail !!!
KD6TH-4*>N2IRZ [I;0,2]:0045z, 745 msgs, #40498 last @KD6TH-4 Mailbox>

N2IRZ didn't get the First packet without errors, but did get the Second, so
it sends:

N2IRZ*>KD6TH-4 [RJ;1]

Which tells KD6TH-4 that it is rejecting the received packet: N2IRZ still
wants packet number 1. If both packets were received OK, N2IRZ would simply
send [RR;3] and the process would continue, but if N2IRZ hadn't received
EITHER packet, no response would have been sent.  Then KD6TH-4 would have
started polling:

KD6TH-4*>N2IRZ [RR,P;0]

N2IRZ would reply

N2IRZ*>KD6TH-4 [RR,F;1]

Eventually, N2IRZ is finished reading the mail, so he signs off:

N2IRZ*>KD6TH-4 [I;5,2]:Bye

This is N2IRZ's frame 2, and he expects frame 5 back. KD6TH-4 responds

KD6TH-4*>N2IRZ [RR;3]
KD6TH-4*>N2IRZ [D,P]

First the "Bye" packet is acknowledged, and then KD6TH-4 initiates a
disconnect. N2IRZ responds

N2IRZ*>KD6TH-4 [UA,F]

and they are disconnected.  KD6TH-4 now sends out its "MAIL_FOR:" beacon:

KD6TH-4*>BBS [UI]: Mail_for: N2DSY WA2SQQ KA2USU W5GZT KB2BAV WA2SPO

This last frame is an Unnumbered Information frame.  The place it is addressed
to (in this case, "BBS") is specified by the UNproto command, which usually
has the default of "CQ".

Now you have a good idea of what C, UA, I, RR, RJ, D and UI frames are like.
A DM frame is sent when the other station is busy, or CONOk is Off, and your
TNC generates a message that "KD6TH-4 is Busy", while KD6TH-4's TNC generates
a "*** Connect Request: N2IRZ" message.
The other frame types are somewhat rare: RNR is sent when one station polls
another ("are you there ?") but the other station isn't ready to process
another packet yet.  FRMR is only sent when all hell breaks loose: the Frame
Type (I, UA, RR, etc) is either undefined or improper protocol (Wrong type of
reply).

If you would like to learn more about the AX.25 Protocol, or Packet Radio in
general, I suggest the following:

Terry Fox, "AX.25 Amateur Packet Radio, Link-Layer Protocol Version 2.0",
(Available from the ARRL), October 1984.

Jim Grubbs, "Get ***CONNECTED to Packet Radio", QSKY Publishing, Springfield,
Illinois. 1986. (Easy to read, great bibliography)

Max Adams, "Basic Amateur Radio Packet", CQ Magazine, November 1985, pp.13-20.


This article is part of an informal series of technical articles intended to
promote experimentation, good operating habits, safety and technical
knowledge. This article may be copied freely, with proper acknowledgement.
Feedback is welcomed.

    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *   73 de Don Rotolo    *    Knowledge is the only instrument   *
    *   N2IRZ@kd6th.nj.usa  *   of production that is not subject   *
    *   CIS : 73227,2644    *  to diminishing returns  -J.M. Clark  *
    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

------------------------------

Date: Tue, 7 Dec 1993 18:45:51 GMT
From: news.kpc.com!kpc!nat@decwrl.dec.com
Subject: W9GR DSP article of Sept 1992 QST
To: ham-digital@ucsd.edu

Hi,
 I just stumbled across W9GR's article and am itching to build it.
I have several questions: 
 1. is the PC board available. I can get hold of the parts locally. 
 2. The article mentions that the TI assembly files for the prom code 
are available on compuserve. Are they also available at some internet ftp site. 
Any pointers would be helpful. 
 3. The article also mentions that the prom programming files are 
also available. Again pointers would be helpful.

 Thanks in advance.
 Nat.

-- 
-------------------------------------------------------------------------
Natarajan Gurumoorthy AB6SJ  Kubota Pacific Computer, Inc.
nat@kpc.com    2630 Walsh Avenue
Phone 408 987 3341   Santa Clara, California 95051.

------------------------------

Date: (null)
From: (null)
>Nevertheless, complaints from computer networking people that tiny,
>fixed-sized cells were not what they needed didn't seem to faze the
>telcos.

ATM just requires a protocol encapsulation/translation.  Nothing much worse
than fragments in TCP/IP.

>|> Also my understanding is that currently all you can get today on
>|> ATM is a permanent virtual circuit, no "dial up".  It appears
>|> that switched service is years away.  And it's not clear how
>|> (if?) ATM will handle multicast traffic.

>A very common misconception about ATM, perhaps encouraged by the
>telcos themselves to sound more trendy, is that ATM is packet
>switching.  It really isn't. First of all, ATM cells look nothing
>like, say, the Ethernet frames with which computer networking people
>are familiar: full source and destination addresses, followed by a
>variable length data field with a reasonably large size limit.  And
>there's too little buffering in an ATM switch to make it a true packet
>network, where lots of little bursty users all contend for each link
>through a queue.

The first time a packet follows a path through any modern routing system,
the router will have to take extra time to compute the destination.  Once
it has cached that address resolution, latter packets take less time to
route.  Why should ATM be any different?  Sure, it makes a packet switched
network look more like a virtual circuit network, but that's just reality.
Most packets go where one has already gone, anyway.

>So to achieve a reasonably low lost-cell rate in ATM, you have to set
>up a circuit in advance and preallocate some fraction of link
>bandwidth. If it isn't used, it goes to waste.  Think of ATM as just
>another TDM (time division multiplex) switch, albeit with somewhat
>finer-grained control over the bandwidth allocations that can be
>made. Other than that, ATM doesn't do much that can't already be done
>by a much simpler cross-connect switch at far lower cost.

ATM would mostly be used to connect together LAN's into larger collections.
With that in consideration, why wouldn't the traffic be fairly steady
between nodes?  It's not like ATM was supposed to run to peoples houses
directly.

>|> Remember, ATM is brought to you by the same people who designed
>|> ISDN as the answer to local telephone service.  Will it follow
>|> the same installation / availability / cost path?

>Most likely, or even worse. ISDN's and ATM's "features" are worse than
>useless to anyone trying to build a real packet switched network like
>the Internet. Oh sure, you *can* use them, and people do when the
>tariffs are right. But all that added complexity buys you nothing over
>a bunch of leased lines. Hence they're worse than useless.

>In the case of ISDN, I don't know anyone who uses it as anything but a
>leased line substitute between local packet routers. And this happens
>only when the telcos price ISDN far enough below their traditionally
>overpriced leased line services to make it worth dealing with ISDN's
>many added hassles. Of course, if the telcos were to price all their
>services according to their true costs, ISDN would immediately
>disappear and they'd have to admit their mistake.

ISDN didn't work out because it took so long to get some switches upgraded.
This brought broadband ISDN closes and caused some of the market demand to
decide to wait for B-ISDN.  *sigh*  Things like that happen.  Remember Floptical
Drives?  They took too long to get to get to market that other technology
like 128Meg MO drives and 140Meg MD drives beat them out.

>Raw digital transmission, at least along major fiber routes, is the
>one thing the telcos know how to do well. Unfortunately, getting just
>that service out of them at a reasonable price is very difficult. Raw
>transmission isn't "glamorous" enough for the telcos, so they keep
>trying to "do it all" (e.g., move into information
>services). Unfortunately, they don't even know how to properly
>*switch* data, much less provide the complete stack including the
>applications.

With this, I can agree.  All I want is a T1 line... *sigh*

>|> What does this have to do with Amateur Radio?  Well, I've been
>|> thinking about all the claims that there isn't enough spectrum to
>|> do Gigabit networking via RF.  Really?  What about local and line
>|> of sight links in the 24Ghz to 100Ghz range?  Sounds hard (a
>|> challange) today, but doesn't sounds like it will remain so...

>Well, IF we were to use ATM, then those claims about insufficient
>spectrum would be true. If we don't, there shouldn't be a problem. :-)

Good dig, but I'm not convinced that ATM is the best for radio use.  Let
me rephrase that.  ATM is very poor for radio use.  One of the prime
assumptions of ATM was that the physical carrier had a very low bit error
rate.  Radio doesn't exactly meet that specification.

Cheers,
David  (N0YMV)
-- 
___________________________________________________________________________
willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | 
David Willmore  | "Ever noticed how much they look like orchids? Lovely!" | 
---------------------------------------------------------------------------

------------------------------

End of Ham-Digital Digest V93 #141
******************************
******************************
